Electronic devices communicate with each other in a variety of ways, often based upon the requirements of a given context. One such context is that of control systems. Unlike simple communication systems where the system merely allows for communication among the devices communicating on the system, control systems communicate for the purpose of explicit control over the modules connected to communicate over the control system. Such systems then allow other applications to run on the various modules. Those applications in a distributed embedded control systems, however, should work in concert.
To provide that group control, most distributed embedded control systems are built around a communication protocol standard, examples of which include CAN (ISO 11898), SERCOS, FlexRay, EtherCAT, and sometimes even Ethernet among others. Higher layer protocols are embedded on top of the communication standard to provide rules for data exchange among participating applications at Electronic Control Units participating in the control network, timing rules, sequence rules, and the like to facilitate communications between the distributed applications that are exchanging information. CANopen, DeviceNet, SDS, J1939, and NMEA 2000 are just a few examples of protocols that are layered on top of the CAN standard. Even meta protocols like CanKingdom are used, by which higher layer protocols can be constructed and optimized for specific distributed embedded control systems.
Each protocol standard has its own strengths and weaknesses. The ideal communication would have an infinite bandwidth, no latency, and full data integrity. Available communication alternatives are fare from the ideal one and compromises have to be found. For instance, Ethernet has a big bandwidth but poor timeliness due to its handling of message collisions. CAN has an efficient collision resolution but low bandwidth and no synchronization support. SERCOS is fast but all nodes have to support the communication requirement of the most demanding node in the system. Accordingly, one big difficulty when designing a distributed embedded control system is to choose the basic communication system to fit the given system's needs. Another complication is that different parts of a system often have different needs. Some parts may involve advanced feedback loops requiring accurate time synchronization and short latencies while other parts may not be time critical at all but instead depend on a correct sequence of events. In another example, a system may during runtime conditions work well with a communication protocol with low bandwidth but would need a high bandwidth for re-flashing modules in a maintenance mode. Moreover, industry requires a number of development and analyzing tools and pool of engineers with an in depth familiarity with the chosen communication protocol to find the correct compromises. To apply the given technologies in a way to take advantage of the good properties of a protocol and to minimize its shortcomings typically requires a long time of practical experience in design and maintenance of distributed embedded control systems based on the chosen protocol and its associated tools.
In the example of CAN systems, the CANFD protocol has been developed in an attempt to address the CAN protocol's data bandwidth limitations. This system, however, is not backward compatible with previous CAN-based modules. Accordingly, modules using the CANFD protocol cannot be installed into a control network having CAN-based modules and effect communication with those modules. Another shortcoming is that the CANFD protocol is based on the modules' looking for a given set point in time, which requires the modules to have highly accurate clocks and processors. Specifically, CAN-FD requires a switch from a first bit-rate to a second bit-rate relative to an edge in combination with the sample point location. This solution demands stable clocks over the time from the edge to the sample point and a common location of the sample point in the definition of the first bit-rate. To get a precise definition of the sample point limits the possible clock frequency that can be used to run the CAN-FD controller. Moreover, although speed is improved over previous CAN-based systems, the maximum message length is still limited to 64 bytes. Such a system lacks in flexibility for system designers.
Moreover, CANFD may present some implementation challenges for current users of CAN-based control systems. In one example, the automotive industry uses CAN-based modules for communication among various elements in a vehicle. Given the nature of the automotive business, simply changing one module in a vehicle's system can be very expensive. Given the challenges facing integration of CANFD modules with CAN modules, to introduce one CANFD module would force an auto maker to either change every module in a given vehicle to CANFD (and absorbing the many multiples of cost to design, build, and test every new module) or split a vehicle's communication bus into two: one running CAN and another running CANFD. Thus, there is a need for a technology that can allow for introduction of CANFD modules gradually over time, such as in the automotive industry, to pre-established CAN-based system to lower the barrier to entry that might otherwise face CANFD modules.